As SASs (Serial Attached SCSI, serial attached small computer system interface) are widely applied to servers and arrays, more devices perform networking by using a SAS domain (SAS domain).
In a SAS host/target (SAS host/target) application, a host/target (host/target) needs to perform interconnect communication with a remote target/host (target/host) by using a SAS Expander (SAS expander). That is, neither communication between a host (host) and a target (target) nor communication between a target and a host is a simple point-to-point direct connection mode any more, and extension needs to be performed by using an expander (expander). Multiple ports (port) are included in a SAS controller. Some ports (port) are directly connected to a remote device, and some ports (port) are interconnected with the remote device by using an expander (expander).
For example, a self-developed host-side SAS controller supports 2K devices (device) and concurrency of 4K IOs (input and output), and a target-side SAS controller supports 64 hosts and concurrency of 256 IOs. Therefore, how to efficiently manage multiple ports (port), multiple devices (device), and concurrency of multiple IOs of each device (device) in the SAS controller is a technical problem that needs to be resolved.
According to a SAS standard protocol layering, ports are independent of one another, and a PL_OC state machine of a port layer (port layer) manages a pending request. The mechanism has a serious problem: there is no strict mapping relationship between a quantity of devices and a quantity of concurrent IOs that are both supported by a SAS controller and a port. If devices and IOs at each port are separately managed, each port needs to manage the devices and the IOs according to a supported maximum specification. As a result, required resource overheads are directly proportional to a quantity of ports in the controller, causing large overheads, and making it difficult to manage.
In a prior-art solution, a to-be-sent task is managed at a software layer, and software dispatches and selects a sending request to instruct hardware (hardware) to perform frame processing. The solution has the following problems:
(1) Each IO has multiple times of interaction between the software and logic, including: the task is delivered to a configuration logic register, the logic completes report interruption, the software searches for a completion status, and the like, thereby causing a great processing delay.
(2) A task queue needs to be maintained in the software, and overheads of cache space of an access queue are large.
(3) Each Port independently manages resources, thereby causing large overheads.